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Abstract 

The Earth Observing System (EOS) Data 
and Operations System (EDOS) is being 
developed by the National Aeronautics and 
Space Administration (NASA) Goddard 
Space Flight Center (GSFC) for the cap- 
ture, level zero processing, distribution, 
and backup archiving of high speed 
telemetry data received from EOS space- 
craft. All data received will conform to the 
Consultative Committee for Space Data 
Standards (CCSDS) recommendations. The 
major EDOS goals are to: 

• Minimize EOS program costs to 
implement and operate EDOS 

• Respond effectively to EOS 
growth requirements 

• Maintain compatibility with exist- 
ing and enhanced versions of 
NASA institutional systems re- 
quired to support EOS space- 
craft. 

In order to meet these goals, the following 
objectives have been defined for EDOS: 

• Standardize EDOS interfaces to 
maximize utility for future re- 
quirements 

• Emphasize life-cycle cost (LCC) 
considerations (rather than pro- 
curement costs) in making design 
decisions and meeting reliability, 
maintainability, availability 
(RMA) and upgradability re- 
quirements 

• Implement data-driven operations 
to the maximum extent possible 
to minimize staffing requirements 
and to maximize system respon- 
siveness 

• Provide a system capable of si- 
multaneously supporting multiple 
spacecraft, each in different 
phases of their life-cycles 
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• Provide for technology insertion 
features to accommodate growth 
and future LCC reductions dur- 
ing the operations phase 

• Provide a system that is suffi- 
ciently robust to accommodate 
incremental performance up- 
grades while supporting opera- 
tions. 

Operations concept working group meet- 
ings were facilitated to help develop the 
EDOS operations concept. This provided a 
cohesive concept that met with approval of 
responsible personnel from the start. This 
approach not only speeded up the 
development process by reducing review 
cycles, it also provided a medium for 
generating good ideas that were immedi- 
ately molded into feasible concepts. The 
operations concept was then used as a basis 
for the EDOS specification. When it was 
felt that concept elements did not support 
detailed requirements, the facilitator process 
was used to resolve discrepancies or to add 
new concept elements to support the 
specification. This method provided an 
ongoing revisal of the operations concept 
and prevented large revisions at the end of 
the requirement analysis phase of system 
development. 

1.0 Introduction 

EDOS operations supports end-to-end data 
delivery for EOS spacecraft. The operations 
concept describes the strategic, tactical, ex- 
ecution and post-execution phases for EOS 
Ground System (EGS) elements, and de- 
scribes the role of EDOS in each phase. In 
support of these phases, the concept de- 
scribes EDOS operations in relation to cur- 
rent and future GSFC Mission Operations 
and Data System Directorate (MO&DSD) 
institutional systems and EOS systems. 
These include the Tracking and Data Relay 
Satellite System (TDRSS) Ground 
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Terminals (TGTs), the Network Control 
Center (NCC), EOS Communications 
(Ecom), as well as EOS Core System 
(ECS) facilities, including the EOS 
Operations Center (EOC), Distributed 
Active Archive Centers (DAACs), and 
other EGS elements. 

The approach used for developing an op- 
erations concept is almost as important as 
the concept itself. In order to be an effective 
concept, it must be well thought out and in 
agreement with the interested parties 
(systems engineers, interface organizations, 
and management). The approach must also 
allow change. This includes a discussion of 
the development of alternative concepts, 
and the tradeoff and other engineering anal- 
yses performed in selecting and developing 
the baseline operations concept. The signif- 
icance of the operations concept in the de- 
velopment of the detailed EDOS functional 
and performance specification and interface 
requirements is described as the "proof of 
concept" of the development method. 

2.0 EDOS Operations Concept 

EDOS is the EOS data handling and 
delivery system maintained and operated by 
the MO&DSD. The development and 
implementation is being managed by the 
Information Processing Division (IPD), 
Code 560, of the MO&DSD at the GSFC. 
EDOS provides capabilities for handling 
data for EOS spacecraft that adhere to rec- 
ommendations established by the CCSDS. 
Specifically, EDOS provides capabilities 
for return link data capture, data handling, 
data distribution, backup archival data 
storage, and forward link data handling. 
EDOS supports ground to ground data 
communications for data delivery using a 
set of approved protocols. Reliance of 
EDOS on these space/ground and ground to 
ground standards facilitates mission 
interoperability and will result in lower 
life-cycle costs for NASA. EDOS supports 
all levels of MO&DSD and EOS end-to-end 
testing in preparation for EOS spacecraft 
launch readiness, by utilizing the 
operational system without interrupting on- 
going operations. Data delivery is provided 
by the SN, EDOS, and Ecom. SN provides 
space/ground data communications. The 


SN consists of the Tracking and Data Relay 
Satellite (TDRS) constellation, the TGTs, 
and the NCC. The TGTs include the White 
Sands Ground Terminal (WSGT) and the 
Second TDRSS Ground Terminal (STGT). 
Space/ground data communications for 
emergency operations are provided by the 
Ground Network (GN), Wallops Orbital 
Tracking Station (WOTS), and the Deep 
Space Network (DSN). Ecom includes the 
wide area network and the Ecom 
Management capability, which provide 
ground to ground data communications 
support for the SN, EDOS, and EGS 
elements. EGS elements include the EOS 
Operations Center (EOC), the Distributed 
Active Archive Centers (DAACs), or other 
associated data handling facilities, such as 
the National Oceanic and Atmospheric 
Administration (NOAA). 

There are three EDOS facilities. The Data 
Interface Facility (DIF) is located at the 
White Sands Complex (WSC) near Las 
Cruces, New Mexico. The Data Production 
Facility (DPF) is located in Fairmont, West 
Virginia. The Sustaining Engineering 
Facility -(SEF) is located in the Data 
Operations Facility (DOF), Building 28 at 
GSFC in Greenbelt, Maryland. 

The capabilities that EDOS provides are 
grouped into categories of services. These 
services are allocated to the three EDOS 
facilities. EDOS services include the data 
delivery services outlined in the previous 
section and the services that support EDOS 
operations. The service categories are des- 
ignated as return link processing, forward 
link processing, operations management, 
production data handling, data archive, 
system support, and engineering support. 
The DIF provides return and forward link 
processing services. The DIF also provides 
operations management services for DIF 
processing services and for the centralized 
EDOS operations management. The DPF 
provides production data handling, data 
archive, and DPF operations management 
services. Return link services are provided 
according to mission-specific requirements. 
The SEF provides sustaining engineering 
services, the EDOS system support coordi- 
nation services and operations monitoring. 
System support services are provided at 
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each of the three facilities to support the op- 
erations at the respective facility. 

2.1 Return and Forward Link 
Processing Operations 

The DIF return and forward link processing 
services provide for the receipt, capture, 
processing, and transfer of digital data that 
conform to applicable CCSDS 
communication services recommendations. 
EDOS acts as an interface between the EGS 
and the SN. Return link processing 
removes communications artifacts and 
provides computer ready data sets to the 
EGS. Telecommand link and physical layer 
services are provided for forward link data 
received via Ecom from the EOC and 
delivered to the EOS spacecraft via the 
TDRSS. Data capture is provided for return 
link data received from spacecraft via the 
TDRSS. Return link services include real- 
time and rate buffered Path and VCDU 
services. Return link data can be delivered 
to any appropriate EGS destination. All 
data handling services, return and forward 
link, include data quality assurance and 
accounting. 

The DIF processing services are highly 
automated data-driven services using man- 
agement information provided by the DIF 
operations management service. The man- 
agement information represents service re- 
quirements for data processing and defines 
the parameters the DIF will use to process 
and deliver data. The DIF incorporates 
built-in test capabilities in support of on- 
line operations. 

The DIF provides the following capabilities 
for the processing and delivery of mission 
data: 

Data Capture. All return link data, including 
fill data, are captured and stored for 30 
days after receipt by EDOS for use in re- 
covery processing. 

^ turn Link Real-time Processing 

Real-time processing receives and pro- 
cesses all return link data, and delivers 
CCSDS Service Data Units (SDUs) (e.g.. 
Virtual Channel Data Units (VCDUs)’ 
CCSDS packets) to EGS elements with 


minimized processing delay through 
EDOS, as required. 

Playback Processing . Playback processing 
restores "as recorded order" to spacecraft 
tape recorded data received by the frame 
synchronization function in reverse order. 
Playback data received in forward order are 
processed and stored as received. Transfer 
of playback data commences after the 
completion of the TDRSS Service Session 


Rate Buffering. Rate buffering is the pro- 
cess in which data from an EOS spacecraft, 
transmitted to the ground during a TSS, are 
completely received by EDOS at one data 
rate and transmitted to destinations at 
negotiated reduced data rates. 

For ward Link Real-time Processing The 
DIF provides the capability to process for- 
ward link data in support of CCSDS 
Telecommand services. 

2.2 Production Data 
Processing Operations 

The DPF provides production data handling 
services for return link mission data re- 
ceived from the DIF. Production data 
handling services annotate and remove, 
when possible, communications artifacts 
and data anomalies due to spacecraft 
operations. These services include 
production data processing and quick-look 
data processing. 

Production Data P rocessing . Production 
data processing of return link CCSDS 
packet data is the process in which packets 
from one or more TSSs are sorted by appli- 
cations process identifier (APID), forward 
ordered by packet sequence count and time, 
and quality-checked. A production data set 
(PDS) consists of production data 
processed packets, quality and accounting 
summary information. Production data sets 
have redundant and previously processed 
packets deleted, and may be delimited by 
time interval, number of packets, number 
of octets of data, or TSS boundary. 

Quick-look Data Processing . Quick-look 
data processing is similar to production data 
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processing except redundant packets are not 
removed and the content of a quick-look 
data set (QDS) is limited to either all pack- 
ets received for a single APID during one 
TSS or all packets in one TSS in which the 
quick-look flag is set in the packet sec- 
ondary header. Quick-look data processing 
may be performed on up to five percent of 
return link data received over a 24-hour pe- 
riod. Quick-look data processing demands 
in excess of five percent will be detected 
and the BOS System Management Center 
(SMC) will be notified about possible 
degradation in EDOS support. The packets 
contained in a QDS are included in produc- 
tion data processing. Specific operational 
requirements for quick-look data process- 
ing will be contained in the Operations 
Agreement (OA) document between the 
EGS element and EDOS. 

2.3 Data Archive Operations 

The DPF data archive service provides a 
long-term storage capability as a Level 0 
data backup to the DAACs. The PDSs cre- 
ated by EDOS are stored for the life of EOS 
plus 3 years. Retrieval of archived data is 
expected to occur infrequently. Retrieved 
PDSs together with quality and accounting 
information are delivered to the requesting 
DA AC as Archive Data Sets (ADSs). The 
data archive service can recover from lost 
or damaged PDSs by receiving and storing 
DAAC to EDOS Data Sets (DEDSs) from a 
DAAC. 

2.4 Operations Management 

EDOS operations management services 
provide the management capability for all 
EDOS resources and services. These ser- 
vices provide highly automated system 
monitoring and control capabilities and 
manage the operation of EDOS services. 

The DIF and DPF operations management 
(OM) capabilities monitor and control the 
systems that implement the services of the 
respective facility. These management ca- 
pabilities receive, consolidate, and analyze 
system performance data as well as respond 
to service requests received by the EDOS 
service management (SM) capability. The 
DIF and DPF OM capabilities transfer ser- 


vice status information to the EDOS SM 
capability for service reporting. 

2.5 System Support Operations 

System support services are provided at all 
three EDOS facilities. These services in- 
clude the capabilities for integration, test, 
and verification (IT&V), fault isolation 
support, and maintenance support for the 
processing services at each facility. 

The EDOS IT&V capability provides tools 
to support EDOS and external testing. 
Maintenance support capabilities at each 
facility provide tools for managing the 
maintenance of systems at the respective 
facility. The EDOS IT&V and maintenance 
activities are coordinated by the system 
support service at the SEF. 

2.6 Sustaining Engineering 
Operations 

The EDOS sustaining engineering 
capability provides an environment for the 
development of system enhancements, 
trouble-shooting and hardware and 
software updates to the operational system. 
The environment supports tracking of the 
operational system performance and 
maintenance history, and the development 
and evaluation of system changes and the 
evaluation of new technologies and 
requirements. 

3.0 Operations Scenarios 

The EDOS operations concept includes 
several operations scenarios to clarify sys- 
tem and interface functional interactions. A 
typical scenario describes real-time return 
link operations during a TSS. 

3.1 Real-time Return Link 
Data Processing Scenario 

a. TGT transfers Channel Access Data 
Units (CADUs) from each TDRSS service 
channel to the designated DIF TGT ports. 
Data capture recognizes data are present and 
starts storing CADUs, including fill 
CADUs. (The following steps apply to 
each TDRSS service channel) 
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b. VCDU service. The return link process- 
ing (RLP) service frame synchronizer rec- 
ognizes CADU frame sync pattern, per- 
forming bit inversion and CADU reversal 
as required. The frame sync is stripped off, 
status data is collected and sent to the DIF 
OM, and the VCDU is passed to the Reed 
Solomon (R-S) decoder. The R-S decoder 
decodes the applicable portion of the 
VCDU (header and/or entire VCDU), and 
strips off the R-S code. The RLP deletes 
fill VCDUs, generates an EDOS Service 
Header (ESH), collects status data for the 
ESH and sends status data to the DIF OM. 
Time and date of CADU receipt by the DIF 
is added to the ESH and the ESH is ap- 
pended to the VCDU, creating a VCDU 
EDOS Data Unit (EDU). Services for the 
VCDU are determined in the RLP by 
checking the service requirements for the 
VCDU-ID [spacecraft ID (SCID) and vir- 
tual channel ID (VCID) located in the 
VCDU header]. Command Link Control 
Words (CLCWs) are extracted from 
VCDUs and transferred in real-time with 
the source VCDU ESH to the EOC. VCDU 
EDUs not requiring Path service are stored. 
VCDU EDUs requiring real-time service 
are transferred to the requesting EGS ele- 
ments. VCDU EDUs requiring Path service 
are sent to the Path service processor. 

c. Path service. VCDU EDUs are disas- 
sembled: packets are extracted and re- 
assembled. Packet fragments with headers 
are filled out with fill data. The source 
VCDU ESH is retained, packet quality and 
accounting data are added to the ESH and 
the ESH is appended to each related packet, 
creating packet EDUs. Packet EDUs are 
then stored. Packet EDUs requiring real- 
time service are concurrently transferred to 
the requesting EGS elements. 

d. VCDU EDUs and packet EDUs requir- 
ing TSS post-operations services are stored 
in a manner that facilitates rapid access, in 
order to start transferring multiple EDU 
files to destinations within 5 minutes. 
Stored files are identified for the type and 
priority of post-TSS processing needed: 
quick-look data processing, playback pro- 
cessing, rate buffering, and production data 
processing). 


e. The DIF OM collects service processing 
status data from each of the DIF processing 
services during processing activities. 
During a TSS, the EDOS SM collects these 
data from the DIF OM and also Ecom's 
service status data, compiles the data into a 
customer operations data accounting 
(CODA) Report, and sends the report to the 
EOC, nominally every 5 seconds, during 
the TSS. SN performance messages are 
received from the NCC and used at the DIF 
along with other status data and SN 
schedule data by the operators for fault 
isolation. The DIF OM also does 
quantitative and quality determination for 
DIF operators and for TSS summary re- 
porting. The EDOS SM also receives TGT 
performance data via the NCC. The EDOS 
SM operator compares TGT performance 
parameters with the RLP status data for 
fault isolation. 

4.0 Operations Concept 
Development Approach 

Traditionally, the responsibility for drafting 
an operations concept for a new system lies 
with one or two knowledgeable people who 
have had some experience in the past with 
such documentation and who have partici- 
pated in high level requirements meetings 
and discussions with the system project 
personnel. The concept is drafted and dis- 
tributed for review. After several draft re- 
visions, the concept eventually gets honed 
into an acceptable product. At best this 
method is a compromise of ideas (concept 
features) of how the system should operate. 
At worst, the concept may be lacking in 
support of key requirements. This could be 
caused by reviewers misinterpreting the 
concept or the writers misinterpreting the 
reviewers' intentions in their comments. 
There is more chance for this to happen if a 
new system is different or more complex 
than existing systems. Reviewers may not 
be persistent enough in their reviews to en- 
sure compliance with their change requests. 
The traditional method was initially tried in 
developing the EDOS operations concept. 
After several unsuccessful attempts to 
satisfy reviewers, a facilitator approach to 
the development was tried. 
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The EDOS Project formed an operations 
concept working group (OCWG) consist- 
ing of EDOS systems engineering team 
(SET) members. The OCWG was 
composed of government and contractor 
project support personnel who had partici- 
pated in Phase B studies and were respon- 
sible for the requirements analyses for 
EDOS. The OCWG met regularly and rep- 
resentatives of systems with EDOS inter- 
faces were invited to participate in the con- 
cept discussions. Each member was 
allowed to express his or her ideas and 
critique the other members' ideas. Members 
shared facilitating of the meetings. This 
avoided over dependence of any one person 
and also avoided the "leader" instinct of 
some of the members. It also increased the 
homogeneity of the meetings. Agendas 
were followed at each meeting. A member 
was delegated to write the minutes 
(including concepts developed). These 
minutes were reviewed in detail at the next 
meeting prior to proceeding with new 
business/concepts. This gave the members 
an opportunity to correct or improve the 
concept as recorded and reach further 
agreement. An important feature of this 
method is that a consensus was reached 
among the responsible project personnel 
before a draft document was started. This 
meant that the critical part of the concept 
development was basically finished before 
documentation began. Another feature was 
that each member’s technical knowledge 
and familiarity with the system require- 
ments were enhanced during the process. 
This was important during the next phase 
of system development which was the re- 
quirement analyses for the EDOS specifica- 
tion. During this phase, the operations con- 
cept was used to understand what require- 
ments were needed for the specification. If 
the concept was found lacking, the facilita- 
tor method was used to develop new or im- 
proved concept features. Since this method 
had been used previously and by the same 
personnel, it was easy to re-institute the 
process. 
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